【レポート】事業責任者も必見！AWS Well-Architected Frameworkのビジネスへの有効活用 #AWSSummit

AWS Summit Tokyo 2019
#AWS Well-Architected Framework
#イベントレポート
#AWS Well-Architected Tool
#AWS Well-Architected
#AWS
中川翔太
2019.06.14
この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。
こんにちは、中川です。
2019/6/12(水)～14(金) の期間で開催されている、AWS Summit 2019 Tokyo からセッションをレポートします。 本記事は「事業責任者も必見！AWS Well-Architected Frameworkのビジネスへの有効活用」についてレポートします。
 セッション概要スピーカー（敬称略）：

・ 柘植翔太（株式会社サイバーエージェント技術本部・サービスリライアビリティグループ）

・ 岡田翔乃介（株式会社サイバーエージェント技術本部・サービスリライアビリティグループ）

セッション名：事業責任者も必見！AWS Well-Architected Framework のビジネスへの有効活用
本セッションでは、株式会社ASTROBOXが提供するサービスである「Ameba占い館SATORI」の事例を元に、プライベートクラウドで運用していたシステムを AWS へ移設する際、どのように AWS Well-Architected Framework を活用したのかについてお話しします。

また、私たちが独自に作っている CA Well-Architected Framework についてもお話しする予定です。
 セッションレポート以下、セッションレポートになります。

なお、Well-Architected Framework は、W-A の略称を使用させていただきます。
 1. Introduction所属する会社について
株式会社サーバーエージェント

所属する組織について
技術本部
社内でメディア管轄と呼ばれているサイバーエージェントグループのメディアやグループを横断的にサポート

サービスリライアビリティグループ
メディア管轄のサービスのインフラ領域を横断的にサポート

メディア管轄と SRG の総管轄
ASTROBOX は Ameba 関連サービス


ASTROBOX について
サイバーエージェント 100%出資子会社
SATORI、SATORI 電話占い

 2. Well-Architected Frameworkシステム移設にあたり抱えていた課題
移設の期限がすでに決まっている
システム構成の悩み
インフラチームへの依存

技術者への提案
AWS についての学習
潜在的なリスクの可視化
W-A を提案

AWS Well-Architected Framework とは
システム設計・運用の大曲的な考え方とベストプラクティス集
最近では、AWS Well-Architected Framework Tool も発表され、セルフチェック可能に

ホワイトペーパーについて
5 つの柱によって構成
運用上の優秀性
セキュリティ
信頼性
パフォーマンス効率
コスト最適化

最近では、IoT やサーバーレス向けのホワイトペーパーも

よくある誤解
AWS W-A を銀の弾丸だとおもっている
あくまで設計の原則
システムの健康診断として使える

監査的な使い方ができると思っている
監査的な使い方は望ましくない
どう改善に取り組むかを一緒に考えることが重要

試しに 1 回実行してみたが良くならない
定期的に実施し、チェックと改善のフローを継続的に回すことが重要


導入フロー
現状のシステム構成を整理
事前に確認質問集へ記入
今は AWS W-A Tool を活用するといい

AWS の SA 同席で、レビュー会を実施
可能な限り技術責任者、決裁権をもつエンジニアが同席するといい

現状のシステム状態の分析
Review Report を元に、システム改善（移設）計画を立てる
このステップが W-A で一番重要
何が問題なのか
問題に対して利害関係者は誰何か
問題箇所の技術領域に詳しいのは誰か
問題箇所を解決する上で誰が責任者か


システム改善（移設）を元に実施

継続的なシステム改善について
Enginieering Budget という考え方
サービスの売上変動に応じてエンジニアリング予算を確保
新しいツールを導入しやすくする
エンジニアのコストも可視化して、事業成長できるように



導入サービスの技術責任者からの声
ポジティブな意見
運用周りのヒントを貰えたので、それをもとに改善していこうと思った
どういったセキュリティリスクがあるのかを認識することができて
運用中のサービスをはじめて AWS に移設したが、安心して取り組めた

その他の意見
項目によっては回答が難しい
課題はわかったが、事業レベルでどう取り組むべきか
定期的にセルフチェックしたい


 3. CA Well-Architected FrameworkCA Well-Architected Framework とは
AWS W-A を元に作成した、プラットフォームに依存しない汎用的なフレームワーク
Yes/No だけで判別できるように
質問数を可能な限り少なく
内製だからできるカスタマイズ
Google Apps Script でレビュー結果の自動集計・解析や Slack 通知を実施する Bot

サービスを見つめ直すためのライフサイクル
学習
測定
コミュニケーション
改善/事業貢献
開発者視点のメリット
より迅速にかつ低リスク
体系的に
導入コストが低い
事業者視点のメリット
どの事業でも提供することができる
サービスの信頼性も向上する
リスクを可視化することができる
CA W-A の実施フロー
CONDITION REVIEW
事前にサービスのコンディションチェック

REVIEW REPORT
ORE とサービスのジグつ責任者でレビュー

DISCUSSION & PLANNING
技術責任者と事業責任者

IMPROVEMENT
CONDITION REVIEW
Google スプレッドシートでコンディションの質問集を管理
カスタマイズした Slack ボタンから Slack にレビュー結果を連携
REVIEW REPORT
Google ドキュメントを利用
すべての項目に関して Suggetion を用意
詳細結果、改善案や事例 etc
DISCUSSION & PLANNING
2 回にわけて実施
事業と技術から優先度を話す
IMPROVEMENT
改善フロー
合意が取れた解決すべき課題を改善
改善事例として、社内外へ公開
半期後に改善率チェック

CA W-A はチェックシートではない
チェックした後のコミュニケーションに価値がある

SATORI の進捗
今は IMPROVEMENT
レビュー結果
優先して改善していく項目（CriticalIssue）に焦点を当てることに

以下のように分類
6 月中に完了予定
今期中に実施
前 2 つが完了したら実施

技術責任者からの FB
どういうことに影響がでそうかまでまとめてきてくれたのでわかりやすかった

事業責任者からの FB
エンジニア以外も理解をしやすい内容であった

CA W-A の今後について
4 つに導入
さらに 2 つに導入予定
2019 年下半期にやるべきこと
自動で前回と光っく
情報の最大化
AWS W-A Tool と統合
母国語の形成
On-boarding の整備と公開

 4. SummaryAWS W-A の可能性
体系的に AWS について学べる
AWS を活用しているサービスであれば AWS W-A を試さない理由はない

プロダクトの成長をお手伝いするために CA W-A を作りました
事業視点と技術視点の双方から自サービスを見つめ直し、根本的な課題をクリアにするための道具
チェックシートではないし、監査として使用するものではない

 さいごにAWS Well-Architected Frameworkとサイバーエージェント社で使用しているCA Well-Architected Frameworkの活用事例について、話していただきました。

W-A をチェックシートとして終わりにするのではなく、定期的に W-A を回すことが重要であり、そのために組織として改善できる環境作りも大事だと思いました。